Update grt, drt, rsz utilities to support RC correlation #7254
Conversation
The `grt::route_layer_lengths` method is used in OR flow scripts to correlate the final parasitic extraction with wire length on individual layers. This way one can extract empirical coefficients for `set_wire_rc`. Enhance this method to include the number of via crossings, and remove "last-mile pin connection patching" which was introducing duplicate vias. Signed-off-by: Martin Povišer <[email protected]>
Signed-off-by: Martin Povišer <[email protected]>
Signed-off-by: Martin Povišer <[email protected]>
Signed-off-by: Martin Povišer <[email protected]>
Signed-off-by: Martin Povišer <[email protected]>
Add a DRT analogue of `grt::route_layer_lenghts` for RC correlation experiments. Signed-off-by: Martin Povišer <[email protected]>
|
clang-tidy review says "All clean, LGTM! 👍" |
| tool_category->writeTR(file_name); | ||
| } | ||
|
|
||
| std::vector<int> TritonRoute::routeLayerLengths(odb::dbWire* wire) const |
There was a problem hiding this comment.
Why is this in drt as it appears only use odb APIs?
There was a problem hiding this comment.
It makes sense to have drt::route_layer_lengths as an analogue to grt::route_layer_lengths. The latter does use grt APIs so it can't be an odb utility. Should I move the drt one into the odb submodule, or just somewhere else in src/drt/src where it's more decoupled from the router itself?
| route_pts.insert(RoutePt(segment.final_x, segment.final_y, layer)); | ||
| } | ||
| } | ||
| // Mimic MakeWireParasitics::makeParasiticsToPin functionality. |
There was a problem hiding this comment.
Why is the following code no longer needed?
There was a problem hiding this comment.
My understanding is the grt guides reach the center of the instance not the individual pins, and this code is adding a small patch of route on top of it to meet the pin. In the process it's adding a redundant via (so we overcount), and I'm not sure the wirelength it adds is beneficial either.
If it's true that it doesn't help with the estimation (which can be confirmed empirically) then we should remove the same code from makeParasiticsPin to keep things in sync
There was a problem hiding this comment.
@povik A small clarification, but GRT guides don't reach the center of the instance. They reach the center of the GCell that encloses the pin shape. The distance from the center of the GCell to the pin location might be useful (more than 7 tracks, for example)
There was a problem hiding this comment.
What is the redundant via that is being added?
There was a problem hiding this comment.
Actually the redundant via exists only in makeParasiticsToPin (see via_res in the function). Here it wasn't being counted because we weren't counting vias at all, but now that we do, we would have a redundant via if we updated this piece of code instead of removing it.
There was a problem hiding this comment.
I'm afraid I'm not following. My concern is that if estimate RC is creating a redundant via then it is incorrect and should be fixed. Perhaps you and @eder-matheus can review this issue.
There was a problem hiding this comment.
We've discussed with @eder-matheus and agreed to put this code back.
My concern is that if estimate RC is creating a redundant via then it is incorrect
There's redundant via in estimate RC but it's a dead end so if STA is considering topology of the parasitic network the extra resistive element is without effect. The length utility doesn't see topology.
Signed-off-by: Martin Povišer <[email protected]>
|
clang-tidy review says "All clean, LGTM! 👍" |
|
@maliberty should be good to go |
4 participants
This adjusts the Tcl utilitites used in OR flow scripts to correlate placement/routing parasitic estimates with final parasitic extraction. The following changes are made:
rsz::sum_parasitic_network_resistutility); this is a replacement for an earlier method of (1) only considering two-pin nets for resistance correlation (2) forcing "pi elmore" reduction of parasitics inside STA (3) looking up the reduced resistance viasta::find_pi_elmore